ℹ️ Issue

Closes #126

📝 Description

This PR was a simple backend update to fix makes donations support reoccurances. We had an implementation suggested in the ticket, which I followed pretty closely. I also made a migration for these changes, ensuring that all fields were considered nullable, until the reoccurance field became somehting other than once.

I also altered the backend create endpoint accordingly. I made it so that, if the recurrance type is not ONCE, then all 3 other fields need to be filled out, or we cannot create a donation.

The idea with this migration now, is that we can easily implement recurruing donations as follows

• On the frontend side: When a manufacturer puts in the information of the recurrance type, how often, and the specific days of the week/day of the month/day of the year, we will use this to calculate our very first nextDonationDates array
• From there, we will implement a continuous check to see whether or not our first element in the array (since it will be the most recent) is the current date. If it is, we will send an email alert, and remove that. We will then use todays date, as well as the recurrance type and frequency, to calculate when the next date will be for the donation, and add that to the end of the array
• We will also decrease the number of occurances when this happens. If the number of occurances becomes 0, then we do not add to the array anymore (we could also potentially delete the donation as well).

✔️ Verification

• Tested that the migration and revert both worked
• Error tested the new create endpoint with proper details

🏕️ (Optional) Future Work / Notes

Now that we have this, we need to being handling actually updating the endpoint daily. This will include the following:

• We will need to implement all of the above flow in the description later on. This should likely be reference for whoever goes to implement it, as this future logic is what the current entity is based on.